…oses #114)

Adds 25 contract tests that pin the envelope shapes each dispatch tier
emits against the handler-side parsers that consume them, so a future
divergence on either side fails fast in CI rather than slipping through
to production.

Background: handler integration tests stub `runAgentDevice` via
`_setRunAgentDeviceForTest` with synthetic envelopes. Codex flagged on
PR #109 (conf 80) that this short-circuits the real wrapper's three
dispatch tiers, each of which produces subtly different shapes. The
original issue listed agent-device's internal tiers (fast-runner HTTP /
daemon socket / CLI), but post-PR #164 (iOS-MVP) and PR #165 (Android-
MVP) the surface widened to include the in-tree iOS and Android runner
clients too. This PR covers the current surface.

Producers pinned:

  1. In-tree iOS runner (rn-fast-runner-client.runIOS) — flat nodes
     with `{ref: '@e<n>', type, rect, label?, identifier?, enabled?,
     hittable?}` shape after mapRunnerNodesToFlat normalization
  2. In-tree Android runner (rn-android-runner-client.runAndroid) —
     identical flat-node shape (the parity test pins this — a divergence
     here would silently break platform-agnostic handlers)
  3. Legacy upstream agent-device daemon socket — flat-nodes with less
     metadata
  4. Legacy upstream agent-device CLI subprocess — separate fixture
     even though current shape equals daemon, so a future divergence
     would surface here
  5. Legacy upstream agent-device internal fast-runner sub-tier —
     nested-tree shape, NOT flat. findRefByTestID's `env.data.tree`
     branch handles this; removing the branch without warning would
     fail this test
  6. iOS XCUIElement.typeText runner-timeout shim — `{ok:true, data:
     {typed, text}, meta: {sideEffectSucceeded, runnerTimeoutShim}}`.
     snapshotEnvelopeFailed must NOT report this as a failure (it would
     route every successful iOS fill to SNAPSHOT_FAILED otherwise)

Consumers exercised:

  - findRefByTestID (device-batch.ts) — both flat-nodes and nested-tree
    branches
  - snapshotEnvelopeFailed (device-batch.ts) — including the critical
    distinction between empty-nodes success (TESTID_NOT_FOUND) and
    snapshot-infrastructure failure (SNAPSHOT_FAILED), per Phase 128 #5/#6
  - Edge cases: null/undefined/empty/malformed JSON all classified as failed

codex-pair caught three fidelity issues during review (MED): my initial
fixtures used `ref: 'app-0'` style refs with `parentIndex`/`depth`
fields, but the actual mapRunnerNodesToFlat output emits `@e<n>` refs
with `type`/`rect`/`enabled`/`hittable`. The failure fixture used the
raw HTTP error shape `{error: {message, code}}` instead of the post-
failResult `{ok:false, error: string, code: string}` shape MCP consumers
actually see. And the comment claimed daemon + CLI were pinned
separately but only daemon was. All three fixed before commit — a
contract test with the wrong fixtures is worse than no contract test
because it gives false confidence.

Verified: 1506/1506 cdp-bridge unit tests passing (+25 net new).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>